Computers and other network devices deployed within an enterprise network rely on virtualization solutions for accessing system resources. For instance, applications, files or even registry values may be virtualized. However, such virtualization requires complete interception and redirection of user/application requests directed to a virtualized system resource, which can interfere with the detection of malicious behavior by the network device that is caused by an exploit or malware present in the device (generally referred to as a “security threat”).
Currently, there exist security appliances that operate within an enterprise network and utilize one or more virtual machines (hereinafter referred to as “VMs”) for analysis of network traffic for maliciousness. According to one deployment, each VM is configured to execute multiple processes concurrently (e.g., operating at least partially at the same time), where two or more of these processes support different versions of application software. Concurrent execution of multiple processes within a VM provides a more comprehensive threat detection solution than single process execution; however, it is extremely difficult to maintain and validate the accuracy of multiple installed applications, as well as to guarantee desired installed software configuration/plugins associations. In fact, installation of multiple versions of the same application may result in a software deployment that does not exist, and perhaps would have never existed on any end-user machine or backend server. Hence, the execution environment may not appear as a “real” machine to a security threat.
For instance, during installation of a new or updated version of application software, some older software components (e.g., dynamic-link library “dll”) may be overwritten with newer versions. As a result, certain malicious attacks may not be observed. For example, multiple versions of Microsoft® Office® may be installed within a system and supported by a VM, such as Office® 2007, Office® 2010 and Office® 2013. During installation, Office® 2007 installs a first dll to the system. During installation of Office® 2010, however, the first dll may be overwritten with a newer version. The removal of the first dll may configure the VM differently than its intended configuration for threat detection, which may cause some malicious attacks to go undetected. Hence, labor intensive reviews are required to ensure that, after undergoing any type of software configuration, a VM maintains an intended software configuration, which are costly and delay malware detection product releases.
More specifically, installing application versions 3.0 and 3.1 may result in an application runtime environment that is a combination of these application versions. If application version 3.0 loads a DLL (module), reads a registry key, or configuration file belonging to version 3.1, then the code path and memory layout result in a hybrid application version 3.0′, which is not equivalent to application version 3.0 or 3.1. If the area of logical change or memory layout change is the target of an exploit, the detection of the actual exploit may fail; however, such detection would have been successful, as the exploit may have run, on a real version 3.0 installation. These levels of runtime behavioral changes are difficult to validate during a quality assurance (QA) verification phase.
Additionally, each process may launch its corresponding application software with a selected software module that adds capabilities to existing application software, such as a unique version of an application plug-in. Hence, the VMs may have the same application software (e.g., Microsoft® Internet Explorer® version 9), but use different flash players (e.g., Adobe® Flash player 13 for one application version and Adobe® Flash player 16 for another application version).
The interchangeability between application software and plug-ins provides a multiplexed virtualization scheme where different versions of virtualized application software may be intentionally associated with different virtualized application plug-ins in order to increase the breadth of malware detection. However, due to the presence of time-out conditions, which require initialization of application plug-ins to be completed within a prescribed period of time after the application software has launched in the VM, it is contemplated that VMs within security appliances may not be configured with an intended application plug-in. Rather, in response to an occurrence of a time-out prior to completing initialization of an application plug-in, the virtualized application software may attempt an association with another application plug-in (e.g., a different version of application plug-in). Hence, again, the VM is now set with a configuration that is different than its intended configuration for threat detection. Without virtualization support it is very difficult to “correctly” simultaneously launch and utilize multiple plugins in multiple applications.